Universal Serial Bus (USB) is a serial bus standard used for connecting peripheral devices to a host computer. A USB system comprises a USB host, a plurality of downstream USB ports, and one or more peripheral devices. A USB host may have multiple USB host controllers (the “host controllers”), wherein each host controller may provide for one or more USB ports.
Specifically, the USB 2.0 architecture offers high-speed communications, and is capable of connecting multiple devices to a hub that is further connected to a port of the host computer. The USB 2.0 architecture employs a unidirectional broadcast system. In such a system, when a host controller or hub sends a packet, all devices downstream from the originating point of the data will receive the packet. When the host controller communicates with a specific device, it must include the address of the device in the Token packet. Upstream traffic (i.e., the responses from the devices) is only received by the host controller and hubs that are directly connected on the return path to the host controller.
This feature of the USB architecture is especially significant for USB analyzers, which communicate to an analysis computer through the USB system. FIG. 1 illustrates a typical setup for connecting an analyzer to a USB system, wherein the analyzer and a device are connected to the same host controller. An analyzer 12 is setup to monitor the communications between a host controller 10 and a device 14. The analyzer 12 can be setup such that the host controller 10 and the device 14 are unaware of the analyzer's presence on the communication line.
Since the analyzer 12 and the device 14 are connected to the same host controller 10, the analyzer 12 will receive traffic (e.g., packet 16) intended for itself and for the device on the communication port 11 and on the monitor port 15. Since packets intended for the communication port 11 of the analyzer 12 are also perceived on the monitor port 15, this creates a positive feedback loop. Every time the computer requests data from the analyzer 12, it actually creates more traffic on the monitor port 15 to be sent back to the computer. The traffic can overwhelm the user with unnecessary data and will also put unnecessary load on the analyzer's buffer memory and the analysis computer. This is especially true when the analyzer 12 sends large volumes of analysis data back to the analysis computer simultaneously to when the traffic is being captured.
It should be noted that this positive feedback occurs only during particular configurations of the analyzer 12 and device 14 on a single host controller 10. High-speed (HS) communication devices are electrically isolated from full-speed (FS) and low-speed (LS) devices, even if connected to the same host controller. Thus, packets to the analyzer 12 will only be perceived on the monitor port 15 if the monitor port 15 is HS and the communication port 11 is HS, or if they are both not HS.
FIG. 2 illustrates the data traffic at various times for an analyzer and a device on the same host controller. Each connection to the host controller 10 effectively has a logical “Send” and “Receive” unit. All packets sent by the host controller 10 (see times t0 and t2) are received by all attached peripherals (i.e., the device 14 and the analyzer 12). The responses from the peripherals (see times t1 and t3) are only seen on the physical communication interface between the particular peripheral and the host controller 10.
When the host controller 10 sends a packet with the data “PKT2ANL” to the analyzer 12 at time t2, the analyzer 12 receives the packet on its receive logical port (of the communication port 11), as well as on its monitor port 15. Therefore, when the analyzer 12 responds with the monitored data at time t3, that piece of data, “PKT2ANL”, is unnecessarily present in the analyzer response. If the host controller 10 is sending many packets to the analyzer 12, then this has the potential of overloading the captured analysis traffic with unnecessary information, and can also take up bandwidth in the analyzer's response at time t3.
Previous products and technologies combated this issue in one of two ways: they either avoided the issue entirely by insisting the user put the USB analyzer on a separate host controller, or they required the user of the analyzer to know the device address of the analyzer beforehand and set up a filter for it.
Using a separate host controller for the analysis computer is optimal in all cases; it reduces the load on that host controller, and allows both the analyzer and the device under test to have more available bandwidth. However, this situation is not always possible or practical, as it requires the user to include additional hardware on the analysis computer or to obtain another USB capable computer; thereby requiring a total of two computers. Therefore, this requirement excludes users from efficiently using the analyzer in such a situation, and does not address the problem.
Some products give the ability to create a hardware filter that will serve a similar purpose. The filter can be configured to discard all data intended for a specific device address. In this way, the analyzer and the device under test can be on the same host controller without overloading the capture buffers. However, these products require the user to know the device address of the analyzer in order to configure the filter. This filter would potentially have to be reconfigured each time the analyzer is used since the device address of the analyzer can change every time it is plugged into a computer. While serving a similar purpose to the present invention, this approach also puts unnecessary strain on the user to maintain the functionality of the filter.
Therefore, it is desirable to provide methods for analyzing USB data traffic using a USB analyzer on a single USB host controller by automatically filtering the USB data traffic.